home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1054.txt < prev    next >
Text File  |  1994-08-01  |  44KB  |  1,062 lines

  1. Network Working Group                                        S. Deering
  2. Request for Comments: 1054                          Stanford University
  3. Obsoletes: RFC 988                                             May 1988
  4.  
  5.  
  6.                   Host Extensions for IP Multicasting
  7.  
  8. 1. STATUS OF THIS MEMO
  9.  
  10.    This memo specifies the extensions required of a host implementation
  11.    of the Internet Protocol (IP) to support multicasting.  It is
  12.    proposed as a standard for IP multicasting in the Internet.  This
  13.    specification is a major revision of RFC-988; changes from RFC-988
  14.    are listed in an Appendix.  Distribution of this memo is unlimited.
  15.  
  16. 2. INTRODUCTION
  17.  
  18.    IP multicasting is defined as the transmission of an IP datagram to a
  19.    "host group", a set of zero or more hosts identified by a single IP
  20.    destination address.  A multicast datagram is delivered to all
  21.    members of its destination host group with the same "best-efforts"
  22.    reliability as regular unicast IP datagrams, i.e., the datagram is
  23.    not guaranteed to arrive intact at all members of the destination
  24.    group or in the same order relative to other datagrams.
  25.  
  26.    The membership of a host group is dynamic; that is, hosts may join
  27.    and leave groups at any time.  There is no restriction on the
  28.    location or number of members in a host group.  A host may be a
  29.    member of more than one group at a time.  A host need not be a member
  30.    of a group to send datagrams to it.
  31.  
  32.    A host group may be permanent or transient.  A permanent group has a
  33.    well-known, administratively assigned IP address.  It is the address,
  34.    not the membership of the group, that is permanent; at any time a
  35.    permanent group may have any number of members, even zero.  Those IP
  36.    multicast addresses that are not reserved for permanent groups are
  37.    available for dynamic assignment to transient groups which exist only
  38.    as long as they have members.
  39.  
  40.    Internetwork forwarding of IP multicast datagrams is handled by
  41.    "multicast routers" which may be co-resident with, or separate from,
  42.    internet gateways.  A host transmits an IP multicast datagram as a
  43.    local network multicast which reaches all immediately-neighboring
  44.    members of the destination host group.  If the datagram has an IP
  45.    time-to-live greater than 1, the multicast router(s) attached to the
  46.    local network take responsibility for forwarding it towards all other
  47.    networks that have members of the destination group.  On those other
  48.    member networks that are reachable within the IP time-to-live, an
  49.  
  50.  
  51.  
  52. Deering                                                         [Page 1]
  53.  
  54. RFC 1054          Host Extensions for IP Multicasting           May 1988
  55.  
  56.  
  57.    attached multicast router completes delivery by transmitting the
  58.    datagram as a local multicast.
  59.  
  60.    This memo specifies the extensions required of a host IP
  61.    implementation to support IP multicasting, where a "host" is any
  62.    internet host or gateway other than those acting as multicast
  63.    routers.  The algorithms and protocols used within and between
  64.    multicast routers are transparent to hosts and will be specified in
  65.    separate documents.  This memo also does not specify how local
  66.    network multicasting is accomplished for all types of network,
  67.    although it does specify the required service interface to an
  68.    arbitrary local network and gives an Ethernet specification as an
  69.    example.  Specifications for other types of network will be the
  70.    subject of future memos.
  71.  
  72. 3. LEVELS OF CONFORMANCE
  73.  
  74.    There are three levels of conformance to this specification:
  75.  
  76.       Level 0: no support for IP multicasting.
  77.  
  78.    There is, at this time, no requirement that all IP implementations
  79.    support IP multicasting.  Level 0 hosts will, in general, be
  80.    unaffected by multicast activity.  The only exception arises on some
  81.    types of local network, where the presence of level 1 or 2 hosts may
  82.    cause misdelivery of multicast IP datagrams to level 0 hosts.  Such
  83.    datagrams can easily be identified by the presence of a class D IP
  84.    address in their destination address field; they should be quietly
  85.    discarded by hosts that do not support IP multicasting.  Class D
  86.    addresses are described in section 4 of this memo.
  87.  
  88.       Level 1: support for sending but not receiving multicast IP
  89.       datagrams.
  90.  
  91.    Level 1 allows a host to partake of some multicast-based services,
  92.    such as resource location or status reporting, but it does not allow
  93.    a host to join any host groups.  An IP implementation may be upgraded
  94.    from level 0 to level 1 very easily and with little new code.  Only
  95.    sections 4, 5, and 6 of this memo are applicable to level 1
  96.    implementations.
  97.  
  98.       Level 2: full support for IP multicasting.
  99.  
  100.    Level 2 allows a host to join and leave host groups, as well as send
  101.    IP datagrams to host groups.  It requires implementation of the
  102.    Internet Group Management Protocol (IGMP) and extension of the IP and
  103.    local network service interfaces within the host.  All of the
  104.    following sections of this memo are applicable to level 2
  105.  
  106.  
  107.  
  108. Deering                                                         [Page 2]
  109.  
  110. RFC 1054          Host Extensions for IP Multicasting           May 1988
  111.  
  112.  
  113.    implementations.
  114.  
  115. 4. HOST GROUP ADDRESSES
  116.  
  117.    Host groups are identified by class D IP addresses, i.e., those with
  118.    "1110" as their high-order four bits.  Class E IP addresses, i.e.,
  119.    those with "1111" as their high-order four bits, are reserved for
  120.    future addressing modes.
  121.  
  122.    In Internet standard "dotted decimal" notation, host group addresses
  123.    range from 224.0.0.0 to 239.255.255.255.  The address 224.0.0.0 is
  124.    guaranteed not to be assigned to any group, and 224.0.0.1 is assigned
  125.    to the permanent group of all IP hosts.  This is used to address all
  126.    multicast hosts on the directly connected network.  There is no
  127.    multicast address (or any other IP address) for all hosts on the
  128.    total Internet.  The addresses of other well-known, permanent groups
  129.    are to be published in "Assigned Numbers".
  130.  
  131.    Appendix II contains some background discussion of several issues
  132.    related to host group addresses.
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164. Deering                                                         [Page 3]
  165.  
  166. RFC 1054          Host Extensions for IP Multicasting           May 1988
  167.  
  168.  
  169. 5. MODEL OF A HOST IP IMPLEMENTATION
  170.  
  171.    The multicast extensions to a host IP implementation are specified in
  172.    terms of the layered model illustrated below.  In this model, ICMP
  173.    and (for level 2 hosts) IGMP are considered to be implemented within
  174.    the IP module, and the mapping of IP addresses to local network
  175.    addresses is considered to be the responsibility of local network
  176.    modules.  This model is for expository purposes only, and should not
  177.    be construed as constraining an actual implementation.
  178.  
  179.          |                                                          |
  180.          |              Upper-Layer Protocol Modules                |
  181.          |__________________________________________________________|
  182.  
  183.       --------------------- IP Service Interface -----------------------
  184.           __________________________________________________________
  185.          |                            |              |              |
  186.          |                            |     ICMP     |     IGMP     |
  187.          |             IP             |______________|______________|
  188.          |           Module                                         |
  189.          |                                                          |
  190.          |__________________________________________________________|
  191.  
  192.       ---------------- Local Network Service Interface -----------------
  193.           __________________________________________________________
  194.          |                            |                             |
  195.          |           Local            | IP-to-local address mapping |
  196.          |          Network           |         (e.g., ARP)         |
  197.          |          Modules           |_____________________________|
  198.          |      (e.g., Ethernet)                                    |
  199.          |                                                          |
  200.  
  201.    To support level 1 multicasting, a host IP implementation must
  202.    support the transmission of multicast IP datagrams.  To support level
  203.    2 IP multicasting, a host must also support the reception of
  204.    multicast IP datagrams.  Each of these two new services is described
  205.    in a separate section, below.  For each service, extensions are
  206.    specified for the IP service interface, the IP module, the local
  207.    network service interface, and an Ethernet local network module.
  208.    Extensions to local network modules other than Ethernet are mentioned
  209.    briefly, but are not specified in detail.
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220. Deering                                                         [Page 4]
  221.  
  222. RFC 1054          Host Extensions for IP Multicasting           May 1988
  223.  
  224.  
  225. 6. SENDING MULTICAST IP DATAGRAMS
  226.  
  227. 6.1. Extensions to the IP Service Interface
  228.  
  229.    Multicast IP datagrams are sent using the same "Send IP" operation
  230.    used to send unicast IP datagrams; an upper-layer protocol module
  231.    merely specifies an IP host group address, rather than an individual
  232.    IP address, as the destination.  However, a number of extensions may
  233.    be necessary or desirable.
  234.  
  235.    First, the service interface should provide a way for the upper-layer
  236.    protocol to specify the IP time-to-live of an outgoing multicast
  237.    datagram, if such a capability does not already exist.  If the
  238.    upper-layer protocol chooses not to specify a time-to-live, it should
  239.    default to 1 for all multicast IP datagrams, so that an explicit
  240.    choice is required to multicast beyond a single network.
  241.  
  242.    Second, for hosts that may be attached to more than one network, the
  243.    service interface should provide a way for the upper-layer protocol
  244.    to identify which network interface is be used for the multicast
  245.    transmission.  Only one interface is used for the initial
  246.    transmission; multicast routers are responsible for forwarding to any
  247.    other networks, if necessary.  If the upper-layer protocol chooses
  248.    not to identify an outgoing interface, a default interface should be
  249.    used, preferably under the control of system management.
  250.  
  251.    Third (level 2 implementations only), for the case in which the host
  252.    is itself a member of a group to which a datagram is being sent, the
  253.    service interface should provide a way for the upper-layer protocol
  254.    to inhibit local delivery of the datagram; by default, a copy of the
  255.    datagram is looped back.  This is a performance optimization for
  256.    upper-layer protocols that restrict the membership of a group to one
  257.    process per host (such as a routing protocol), or that handle
  258.    loopback of group communication at a higher layer (such as a
  259.    multicast transport protocol).
  260.  
  261. 6.2. Extensions to the IP Module
  262.  
  263.    To support the sending of multicast IP datagrams, the IP module must
  264.    be extended to recognize IP host group addresses when routing
  265.    outgoing datagrams.  Most IP implementations include the following
  266.    logic:
  267.  
  268.         if IP-destination is on the same local network,
  269.            send datagram locally to IP-destination
  270.         else
  271.            send datagram locally to GatewayTo( IP-destination )
  272.  
  273.  
  274.  
  275.  
  276. Deering                                                         [Page 5]
  277.  
  278. RFC 1054          Host Extensions for IP Multicasting           May 1988
  279.  
  280.  
  281.    To allow multicast transmissions, the routing logic must be changed
  282.    to:
  283.  
  284.         if IP-destination is on the same local network
  285.         or IP-destination is a host group,
  286.            send datagram locally to IP-destination
  287.         else
  288.            send datagram locally to GatewayTo( IP-destination )
  289.  
  290.  
  291.    If the sending host is itself a member of the destination group, a
  292.    copy of the outgoing datagram must be looped-back for local delivery,
  293.    unless inhibited by the sender.  (Level 2 implementations only.)
  294.  
  295.    A host group address should not be placed in the source address field
  296.    or anywhere in a source routing option of an outgoing IP datagram.
  297.  
  298. 6.3. Extensions to the Local Network Service Interface
  299.  
  300.    No change to the local network service interface is required to
  301.    support the sending of multicast IP datagrams.  The IP module merely
  302.    specifies an IP host group destination, rather than an individual IP
  303.    destination, when it invokes the existing "Send Local" operation.
  304.  
  305. 6.4. Extensions to an Ethernet Local Network Module
  306.  
  307.    The Ethernet directly supports the sending of local multicast packets
  308.    by allowing multicast addresses in the destination field of Ethernet
  309.    packets.  All that is needed to support the sending of multicast IP
  310.    datagrams is a procedure for mapping IP host group addresses to
  311.    Ethernet multicast addresses.
  312.  
  313.    An IP host group address is mapped to an Ethernet multicast address
  314.    by placing the low-order 23-bits of the IP address into the low-order
  315.    23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex).
  316.    Because there are 28 significant bits in an IP host group address,
  317.    more than one host group address may map to the same Ethernet
  318.    multicast address.
  319.  
  320. 6.5. Extensions to Local Network Modules other than Ethernet
  321.  
  322.    Other networks that directly support multicasting, such as rings or
  323.    buses conforming to the IEEE 802.2 standard, may be handled the same
  324.    way as Ethernet for the purpose of sending multicast IP datagrams.
  325.    For a network that supports broadcast but not multicast, such as the
  326.    Experimental Ethernet, all IP host group addresses may be mapped to a
  327.    single local broadcast address (at the cost of increased overhead on
  328.    all local hosts).  For a point-to-point link joining two hosts (or a
  329.  
  330.  
  331.  
  332. Deering                                                         [Page 6]
  333.  
  334. RFC 1054          Host Extensions for IP Multicasting           May 1988
  335.  
  336.  
  337.    host and a multicast router), multicasts should be transmitted
  338.    exactly like unicasts.  For a store-and-forward network like the
  339.    ARPANET or a public X.25 network, all IP host group addresses might
  340.    be mapped to the well-known local address of an IP multicast router;
  341.    a router on such a network would take responsibility for completing
  342.    multicast delivery within the network as well as among networks.
  343.  
  344. 7. RECEIVING MULTICAST IP DATAGRAMS
  345.  
  346. 7.1. Extensions to the IP Service Interface
  347.  
  348.    Incoming multicast IP datagrams are received by upper-layer protocol
  349.    modules using the same "Receive IP" operation as normal, unicast
  350.    datagrams.  Selection of a destination upper-layer protocol is based
  351.    on the protocol field in the IP header, regardless of the destination
  352.    IP address.  However, before any datagrams destined to a particular
  353.    group can be received, an upper-layer protocol must ask the IP module
  354.    to join that group.  Thus, the IP service interface must be extended
  355.    to provide two new operations:
  356.  
  357.                  JoinHostGroup  ( group-address, interface )
  358.  
  359.                  LeaveHostGroup ( group-address, interface )
  360.  
  361.    The JoinHostGroup operation requests that this host become a member
  362.    of the host group identified by "group-address" on the given network
  363.    interface.  The LeaveGroup operation requests that this host give up
  364.    its membership in the host group identified by "group-address" on the
  365.    given network interface.  The interface argument may be omitted on
  366.    hosts that may be attached to only one network.  For hosts that may
  367.    be attached to more than one network, the upper-layer protocol may
  368.    choose to leave the interface unspecified, in which case the request
  369.    will apply to the default interface for sending multicast datagrams
  370.    (see section 6.1).
  371.  
  372.    It is permissible to join the same group on more than one interface,
  373.    in which case duplicate multicast datagrams may be received.  It is
  374.    also permissible for more than one upper-layer protocol to request
  375.    membership in the same group.
  376.  
  377.    Both operations should return immediately (i.e., they are non-
  378.    blocking operations), indicating success or failure.  Either
  379.    operation may fail due to an invalid group address or interface
  380.    identifier.  JoinHostGroup may fail due to lack of local resources.
  381.    LeaveHostGroup may fail because the host does not belong to the given
  382.    group on the given interface.  LeaveHostGroup may succeed, but the
  383.    membership persist, if more than one upper-layer protocol has
  384.    requested membership in the same group.
  385.  
  386.  
  387.  
  388. Deering                                                         [Page 7]
  389.  
  390. RFC 1054          Host Extensions for IP Multicasting           May 1988
  391.  
  392.  
  393. 7.2. Extensions to the IP Module
  394.  
  395.    To support the reception of multicast IP datagrams, the IP module
  396.    must be extended to maintain a list of host group memberships
  397.    associated with each network interface.  An incoming datagram
  398.    destined to one of those groups is processed exactly the same way as
  399.    datagrams destined to one of the host's individual addresses.
  400.  
  401.    Incoming datagrams destined to groups to which the host does not
  402.    belong are discarded without generating any error report.  On hosts
  403.    attached to more than one network, if a datagram arrives via one
  404.    network interface, destined for a group to which the host belongs
  405.    only on a different interface, the datagram is quietly discarded.
  406.    (These cases should occur only as a result of inadequate multicast
  407.    address filtering in a local network module.)
  408.  
  409.    An incoming datagram is not rejected for having an IP time-to-live of
  410.    1 (i.e., the time-to-live should not automatically be decremented on
  411.    arriving datagrams that are not being forwarded).  An incoming
  412.    datagram is not rejected for having an IP host group address in its
  413.    source address field or anywhere in a source routing option.  An ICMP
  414.    error message (Destination Unreachable, Time Exceeded, Parameter
  415.    Problem, Source Quench, or Redirect) is never generated in response
  416.    to a datagram destined to an IP host group.
  417.  
  418.    The list of host group memberships is updated in response to
  419.    JoinHostGroup and LeaveHostGroup requests from upper-layer protocols.
  420.    Each membership should have an associated reference count or similar
  421.    mechanism to handle multiple requests to join and leave the same
  422.    group.  On the first request to join and the last request to leave a
  423.    group on a given interface, the local network module for that
  424.    interface is notified, so that it may update its multicast reception
  425.    filter (see section 7.3).
  426.  
  427.    The IP module must also be extended to implement the IGMP protocol,
  428.    specified in Appendix I. IGMP is used to keep neighboring multicast
  429.    routers informed of the host group memberships present on a
  430.    particular local network.  To support IGMP, every level 2 host must
  431.    join the "all-hosts" group (address 224.0.0.1) on each network
  432.    interface at initialization time and must remain a member for as long
  433.    as the host is active.
  434.  
  435.    (Datagrams addressed to the all-hosts group are recognized as a
  436.    special case by the multicast routers and are never forwarded beyond
  437.    a single network, regardless of their time-to-live.  Thus, the all-
  438.    hosts address may not be used as an internet-wide broadcast address.
  439.    For the purpose of IGMP, membership in the all-hosts group is really
  440.    necessary only while the host belongs to at least one other group.
  441.  
  442.  
  443.  
  444. Deering                                                         [Page 8]
  445.  
  446. RFC 1054          Host Extensions for IP Multicasting           May 1988
  447.  
  448.  
  449.    However, it is specified that the host shall remain a member of the
  450.    all-hosts group at all times because (1) it is simpler, (2) the
  451.    frequency of reception of unnecessary IGMP queries should be low
  452.    enough that overhead is negligible, and (3) the all-hosts address may
  453.    serve other routing-oriented purposes, such as advertising the
  454.    presence of gateways or resolving local addresses.)
  455.  
  456. 7.3. Extensions to the Local Network Service Interface
  457.  
  458.    Incoming local network multicast packets are delivered to the IP
  459.    module using the same "Receive Local" operation as local network
  460.    unicast packets.  To allow the IP module to tell the local network
  461.    module which multicast packets to accept, the local network service
  462.    interface is extended to provide two new operations:
  463.  
  464.                       JoinLocalGroup  ( group-address )
  465.  
  466.                       LeaveLocalGroup ( group-address )
  467.  
  468.    where "group-address" is an IP host group address.  The
  469.    JoinLocalGroup operation requests the local network module to accept
  470.    and deliver up subsequently arriving packets destined to the given IP
  471.    host group address.  The LeaveLocalGroup operation requests the local
  472.    network module to stop delivering up packets destined to the given IP
  473.    host group address.  The local network module is expected to map the
  474.    IP host group addresses to local network addresses as required to
  475.    update its multicast reception filter.  Any local network module is
  476.    free to ignore LeaveLocalGroup requests, and may deliver up packets
  477.    destined to more addresses than just those specified in
  478.    JoinLocalGroup requests, if it is unable to filter incoming packets
  479.    adequately.
  480.  
  481.    The local network module must not deliver up any multicast packets
  482.    that were transmitted from that module; loopback of multicasts is
  483.    handled at the IP layer or higher.
  484.  
  485. 7.4. Extensions to an Ethernet Local Network Module
  486.  
  487.    To support the reception of multicast IP datagrams, an Ethernet
  488.    module must be able to receive packets addressed to the Ethernet
  489.    multicast addresses that correspond to the host's IP host group
  490.    addresses.  It is highly desirable to take advantage of any address
  491.    filtering capabilities that the Ethernet hardware interface may have,
  492.    so that the host receives only those packets that are destined to it.
  493.  
  494.    Unfortunately, many current Ethernet interfaces have a small limit on
  495.    the number of addresses that the hardware can be configured to
  496.    recognize.  Nevertheless, an implementation must be capable of
  497.  
  498.  
  499.  
  500. Deering                                                         [Page 9]
  501.  
  502. RFC 1054          Host Extensions for IP Multicasting           May 1988
  503.  
  504.  
  505.    listening on an arbitrary number of Ethernet multicast addresses,
  506.    which may mean "opening up" the address filter to accept all
  507.    multicast packets during those periods when the number of addresses
  508.    exceeds the limit of the filter.
  509.  
  510.    For interfaces with inadequate hardware address filtering, it may be
  511.    desirable (for performance reasons) to perform Ethernet address
  512.    filtering within the software of the Ethernet module.  This is not
  513.    mandatory, however, because the IP module performs its own filtering
  514.    based on IP destination addresses.
  515.  
  516. 7.5. Extensions to Local Network Modules other than Ethernet
  517.  
  518.    Other multicast networks, such as IEEE 802.2 networks, can be handled
  519.    the same way as Ethernet for the purpose of receiving multicast IP
  520.    datagrams.  For pure broadcast networks, such as the Experimental
  521.    Ethernet, all incoming broadcast packets can be accepted and passed
  522.    to the IP module for IP-level filtering.  On point-to-point or
  523.    store-and-forward networks, multicast IP datagrams will arrive as
  524.    local network unicasts, so no change to the local network module
  525.    should be necessary.
  526.  
  527. APPENDIX I. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP)
  528.  
  529.    The Internet Group Management Protocol (IGMP) is used by IP hosts to
  530.    report their host group memberships to any immediately-neighboring
  531.    multicast routers.  IGMP is an asymmetric protocol and is specified
  532.    here from the point of view of a host, rather than a multicast
  533.    router.  (IGMP may also be used, symmetrically or asymmetrically,
  534.    between multicast routers.  Such use is not specified here.)
  535.  
  536.    Like ICMP, IGMP is a integral part of IP.  It is required to be
  537.    implemented by all hosts conforming to level 2 of the IP multicasting
  538.    specification.  IGMP messages are encapsulated in IP datagrams, with
  539.    an IP protocol number of 2.  All IGMP messages of concern to hosts
  540.    have the following format:
  541.  
  542.        0                   1                   2                   3
  543.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  544.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  545.       |Version| Type  |    Unused     |           Checksum            |
  546.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  547.       |                         Group Address                         |
  548.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556. Deering                                                        [Page 10]
  557.  
  558. RFC 1054          Host Extensions for IP Multicasting           May 1988
  559.  
  560.  
  561.       Version
  562.  
  563.          This memo specifies version 1 of IGMP.  Version 0 is specified
  564.          in RFC-988 and is now obsolete.
  565.  
  566.       Type
  567.  
  568.          There are two types of IGMP message of concern to hosts:
  569.  
  570.             1 = Host Membership Query
  571.             2 = Host Membership Report
  572.  
  573.       Unused
  574.  
  575.          Unused field, zeroed when sent, ignored when received.
  576.  
  577.       Checksum
  578.  
  579.          The checksum is the 16-bit one's complement of the one's
  580.          complement sum of the 8-octet IGMP message.  For computing
  581.          the checksum, the checksum field is zeroed.
  582.  
  583.       Group Address
  584.  
  585.          In a Host Membership Query message, the group address field
  586.          is zeroed when sent, ignored when received.
  587.  
  588.          In a Host Membership Report message, the group address field
  589.          holds the IP host group address of the group being reported.
  590.  
  591. Informal Protocol Description
  592.  
  593.    Multicast routers send Host Membership Query messages (hereinafter
  594.    called Queries) to discover which host groups have members on their
  595.    attached local networks.  Queries are addressed to the all-hosts
  596.    group (address 224.0.0.1), and carry an IP time-to-live of 1.
  597.  
  598.    Hosts respond to a Query by generating Host Membership Reports
  599.    (hereinafter called Reports), reporting each host group to which they
  600.    belong on the network interface from which the Query was received.
  601.    In order to avoid an "implosion" of concurrent Reports and to reduce
  602.    the total number of Reports transmitted, two techniques are used:
  603.  
  604.       1. When a host receives a Query, rather than sending Reports
  605.          immediately, it starts a report delay timer for each of its
  606.          group memberships on the network interface of the incoming
  607.          Query.  Each timer is set to a different, randomly-chosen
  608.          value between zero and D seconds.  When a timer expires, a
  609.  
  610.  
  611.  
  612. Deering                                                        [Page 11]
  613.  
  614. RFC 1054          Host Extensions for IP Multicasting           May 1988
  615.  
  616.  
  617.          Report is generated for the corresponding host group.  Thus,
  618.          Reports are spread out over a D second interval instead of
  619.          all occurring at once.
  620.  
  621.       2. A Report is sent with an IP destination address equal to the
  622.          host group address being reported, and with an IP
  623.          time-to-live of 1, so that other members of the same group on
  624.          the same network can overhear the Report.  If a host hears a
  625.          Report for a group to which it belongs on that network, the
  626.          host stops its own timer for that group and does not generate
  627.          a Report for that group.  Thus, in the normal case, only one
  628.          Report will be generated for each group present on the
  629.          network, by the member host whose delay timer expires first.
  630.          Note that the multicast routers receive all IP multicast
  631.          datagrams, and therefore need not be addressed explicitly.
  632.          Further note that the routers need not know which hosts
  633.          belong to a group, only that at least one host belongs to a
  634.          group on a particular network.
  635.  
  636.    There are two exceptions to the behavior described above.  First, if
  637.    a report delay timer is already running for a group membership when a
  638.    Query is received, that timer is not reset to a new random value, but
  639.    rather allowed to continue running with its current value.  Second, a
  640.    report delay timer is never set for a host's membership in the all-
  641.    hosts group (224.0.0.1), and that membership is never reported.
  642.  
  643.    If a host uses a pseudo-random number generator to compute the
  644.    reporting delays, one of the host's own individual IP address should
  645.    be used as part of the seed for the generator, to reduce the chance
  646.    of multiple hosts generating the same sequence of delays.
  647.  
  648.    A host should confirm that a received Report has the same IP host
  649.    group address in its IP destination field and its IGMP group address
  650.    field, to ensure that the host's own Report is not cancelled by an
  651.    erroneous received Report.  A host should quietly discard any IGMP
  652.    message of type other than Host Membership Query or Host Membership
  653.    Report.
  654.  
  655.    Multicast routers send Queries periodically to refresh their
  656.    knowledge of memberships present on a particular network.  If no
  657.    Reports are received for a particular group after some number of
  658.    Queries, the routers assume that that group has no local members and
  659.    that they need not forward remotely-originated multicasts for that
  660.    group onto the local network.  Queries are normally sent infrequently
  661.    (no more than once a minute) so as to keep the IGMP overhead on hosts
  662.    and networks very low.  However, when a multicast router starts up,
  663.    it may issue several closely-space Queries in order to quickly build
  664.    up its knowledge of local memberships.
  665.  
  666.  
  667.  
  668. Deering                                                        [Page 12]
  669.  
  670. RFC 1054          Host Extensions for IP Multicasting           May 1988
  671.  
  672.  
  673.    When a host joins a new group, it should immediately transmit a
  674.    Report for that group, rather than waiting for a Query, in case it is
  675.    the first member of that group on the network.  To cover the
  676.    possibility of the initial Report being lost or damaged, it is
  677.    recommended that it be repeated once or twice after short delays.  (A
  678.    simple way to accomplish this is to act as if a Query had been
  679.    received for that group only, setting the group's random report delay
  680.    timer.  The state transition diagram below illustrates this
  681.    approach.)
  682.  
  683.    Note that, on a network with no multicast routers present, the only
  684.    IGMP traffic is the one or more Reports sent whenever a host joins a
  685.    new group.
  686.  
  687. State Transition Diagram
  688.  
  689.    IGMP behavior is more formally specified by the state transition
  690.    diagram below.  A host may be in one of three possible states, with
  691.    respect to any single IP host group on any single network interface:
  692.  
  693.       - Non-Member state, when the host does not belong to the group
  694.         on the interface.  This is the initial state for all
  695.         memberships on all network interfaces; it requires no storage
  696.         in the host.
  697.  
  698.       - Delaying Member state, when the host belongs to the group on
  699.         the interface and has a report delay timer running for that
  700.         membership.
  701.  
  702.       - Idle Member state, when the host belongs to the group on the
  703.         interface and does not have a report delay timer running for
  704.         that membership.
  705.  
  706.    There are five significant events that can cause IGMP state
  707.    transitions:
  708.  
  709.       - "join group" occurs when the host decides to join the group on
  710.         the interface.  It may occur only in the Non-Member state.
  711.  
  712.       - "leave group" occurs when the host decides to leave the group
  713.         on the interface.  It may occur only in the Delaying Member
  714.         and Idle Member states.
  715.  
  716.       - "query received" occurs when the host receives a valid IGMP
  717.         Host Membership Query message.  To be valid, the Query message
  718.         must be at least 8 octets long and have a correct IGMP
  719.         checksum.  A single Query applies to all memberships on the
  720.         interface from which the Query is received.  It is ignored for
  721.  
  722.  
  723.  
  724. Deering                                                        [Page 13]
  725.  
  726. RFC 1054          Host Extensions for IP Multicasting           May 1988
  727.  
  728.  
  729.         memberships in the Non-Member or Delaying Member state.
  730.  
  731.       - "report received" occurs when the host receives a valid IGMP
  732.         Host Membership Report message.  To be valid, the Report
  733.         message must be at least 8 octets long, have a correct IGMP
  734.         checksum, and contain the same IP host group address in its IP
  735.         destination field and its IGMP group address field.  A Report
  736.         applies only to the membership in the group identified by the
  737.         Report, on the interface from which the Report is received.
  738.         It is ignored for memberships in the Non-Member or Idle Member
  739.         state.
  740.  
  741.       - "timer expired" occurs when the report delay timer for the
  742.         group on the interface expires.  It may occur only in the
  743.         Delaying Member state.
  744.  
  745.    All other events, such as receiving invalid IGMP messages, or IGMP
  746.    messages other than Query or Report, are ignored in all states.
  747.  
  748.    There are three possible actions that may be taken in response to the
  749.    above events:
  750.  
  751.       - "send report" for the group on the interface.
  752.  
  753.       - "start timer" for the group on the interface, using a random
  754.         delay value between 0 and D seconds.
  755.  
  756.       - "stop timer" for the group on the interface.
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780. Deering                                                        [Page 14]
  781.  
  782. RFC 1054          Host Extensions for IP Multicasting           May 1988
  783.  
  784.  
  785.    In the following diagram, each state transition arc is labelled with
  786.    the event that causes the transition, and, in parentheses, any
  787.    actions taken during the transition.
  788.  
  789.                               ________________
  790.                              |                |
  791.                              |                |
  792.                              |                |
  793.                              |                |
  794.                    --------->|   Non-Member   |<---------
  795.                   |          |                |          |
  796.                   |          |                |          |
  797.                   |          |                |          |
  798.                   |          |________________|          |
  799.                   |                   |                  |
  800.                   | leave group       | join group       | leave group
  801.                   | (stop timer)      |(send report,     |
  802.                   |                   | start timer)     |
  803.           ________|________           |          ________|________
  804.          |                 |<---------          |                 |
  805.          |                 |                    |                 |
  806.          |                 |<-------------------|                 |
  807.          |                 |   query received   |                 |
  808.          | Delaying Member |    (start timer)   |   Idle Member   |
  809.          |                 |------------------->|                 |
  810.          |                 |   report received  |                 |
  811.          |                 |    (stop timer)    |                 |
  812.          |_________________|------------------->|_________________|
  813.                                 timer expired
  814.                                 (send report)
  815.  
  816.    The all-hosts group (address 224.0.0.1) is handled as a special case.
  817.    The host starts in Idle Member state for that group on every
  818.    interface, never transitions to another state, and never sends a
  819.    report for that group.
  820.  
  821. Protocol Parameters
  822.  
  823.    The maximum report delay, D, is 10 seconds.
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836. Deering                                                        [Page 15]
  837.  
  838. RFC 1054          Host Extensions for IP Multicasting           May 1988
  839.  
  840.  
  841. APPENDIX II. HOST GROUP ADDRESS ISSUES
  842.  
  843.    This appendix is not part of the IP multicasting specification, but
  844.    provides background discussion of several issues related to IP host
  845.    group addresses.
  846.  
  847. Group Address Binding
  848.  
  849.    The binding of IP host group addresses to physical hosts may be
  850.    considered a generalization of the binding of IP unicast addresses.
  851.    An IP unicast address is statically bound to a single local network
  852.    interface on a single IP network.  An IP host group address is
  853.    dynamically bound to a set of local network interfaces on a set of IP
  854.    networks.
  855.  
  856.    It is important to understand that an IP host group address is NOT
  857.    bound to a set of IP unicast addresses.  The multicast routers do not
  858.    need to maintain a list of individual members of each host group.
  859.    For example, a multicast router attached to an Ethernet need
  860.    associate only a single Ethernet multicast address with each host
  861.    group having local members, rather than a list of the members'
  862.    individual IP or Ethernet addresses.
  863.  
  864. Group Addresses as Logical Addresses
  865.  
  866.    Host group addresses have been defined specifically for use in the
  867.    destination address field of multicast IP datagrams.  However, the
  868.    fact that group addresses are location-independent (they are not
  869.    statically bound to a single network interface) suggests possible
  870.    uses as more general "logical addresses", both in the source as well
  871.    as the destination address field of datagrams.  For example, a mobile
  872.    IP host might have a host group address as its only identity, used as
  873.    the source of datagrams it sends.  Whenever the mobile host moved
  874.    from one network to another, it would join its own group on the new
  875.    network and depart from the group on the old network.  Other hosts
  876.    communicating with the mobile one would deal only with the group
  877.    address and would be unaware of, and unaffected by, the changing
  878.    network location of the mobile host.
  879.  
  880.    Host group addresses cannot, however, be used to solve all problems
  881.    of internetwork logical addressing, such as delivery to the "nearest"
  882.    or the "least loaded" network interface of a multi-homed host.
  883.    Furthermore, there are hazards in using group addresses in the source
  884.    address field of datagrams when the group actually contains more than
  885.    one host.  For instance, the IP datagram reassembly algorithm relies
  886.    on every host using a different source address.  Also, errors in a
  887.    datagram sent with a group source address may result in error reports
  888.    being returned to all members of the group, not just the sender.  In
  889.  
  890.  
  891.  
  892. Deering                                                        [Page 16]
  893.  
  894. RFC 1054          Host Extensions for IP Multicasting           May 1988
  895.  
  896.  
  897.    view of these hazards, this memo specifies the use of host group
  898.    addresses only in the IP destination address field.  However, it is
  899.    recommended that datagrams with a group source address, or a group
  900.    address as part of a source routing option, be accepted without
  901.    complaint, thereby allowing other implementations to experiment with
  902.    logical addressing applications of host group addresses.
  903.  
  904. Allocation of Transient Host Group Addresses
  905.  
  906.    This memo does not specify how transient group address are allocated.
  907.    It is anticipated that different portions of the IP transient host
  908.    group address space will be allocated using different techniques.
  909.    For example, there may be a number of servers that can be contacted
  910.    to acquire a new transient group address.  Some higher-level
  911.    protocols (such as VMTP, specified in RFC-1045) may generate higher-
  912.    level transient "process group" or "entity group" addresses which are
  913.    then algorithmically mapped to a subset of the IP transient host
  914.    group addresses, similarly to the way that IP host group addresses
  915.    are mapped to Ethernet multicast addresses.  A portion of the IP
  916.    group address space may be set aside for random allocation by
  917.    applications that can tolerate occasional collisions with other
  918.    multicast users, perhaps generating new addresses until a suitably
  919.    "quiet" one is found.
  920.  
  921.    In general, a host cannot assume that datagrams sent to any host
  922.    group address will reach only the intended hosts, or that datagrams
  923.    received as a member of a transient host group are intended for the
  924.    recipient.  Misdelivery must be detected at a level above IP, using
  925.    higher-level identifiers or authentication tokens.  Information
  926.    transmitted to a host group address should be encrypted or governed
  927.    by administrative routing controls if the sender is concerned about
  928.    unwanted listeners.
  929.  
  930. APPENDIX III. CHANGES FROM RFC-988
  931.  
  932.    The IP multicast extensions specified in this memo are significantly
  933.    different from those specified in RFC-988.  Most of the changes are
  934.    due to a shift of responsibility away from the multicast routers
  935.    (called "multicast agents" in RFC-988) and onto the hosts.  This new
  936.    distribution of responsibility is consistent with the lightweight,
  937.    soft-state gateway architecture of the Internet, and it allows the IP
  938.    multicast services (in the same way as the IP unicast services) to be
  939.    used among hosts on a single network when no router is up or present
  940.    on the network.  Thus, current single-network IP broadcast
  941.    applications may be migrated to the use of IP multicast before
  942.    multicast routers are widely available.  The following changes are a
  943.    consequence of this shift of responsibility:
  944.  
  945.  
  946.  
  947.  
  948. Deering                                                        [Page 17]
  949.  
  950. RFC 1054          Host Extensions for IP Multicasting           May 1988
  951.  
  952.  
  953.       - Private hosts groups and access keys have been eliminated.
  954.         The multicast routers are no longer considered trustworthy
  955.         controllers of group membership; it is up to hosts and their
  956.         administrators to provide their own mechanisms to prevent
  957.         unwanted eavesdropping on group communication, perhaps by
  958.         using end-to-end encryption or by imposing restrictions on the
  959.         flow of IP multicast datagrams into and out of particular
  960.         administrative domains.
  961.  
  962.       - The CreateHostGroup operation has been eliminated.  The
  963.         responsibility for allocating transient host groups has been
  964.         moved from multicast routers to the hosts.  See Appendix II
  965.         for a brief discussion of some ways in which hosts might do
  966.         their own transient group allocation.
  967.  
  968.       - The JoinHostGroup and LeaveHostGroup operations have become
  969.         non-blocking, because it is no longer necessary to await
  970.         approval from a multicast router when changing membership.  It
  971.         is also no longer possible for a host to have its membership
  972.         revoked by a multicast router.
  973.  
  974.       - The IGMP protocol is substantially different from that in
  975.         RFC-988, reflecting the changed roles of hosts and multicast
  976.         routers.
  977.  
  978.       - The new IGMP requires that there be an "all-hosts" group.
  979.         There is no longer a need for an "all-multicast-agents" group.
  980.  
  981.    Other changes that are not related to the shift of responsibility
  982.    are:
  983.  
  984.       - The decision whether or not to loop back a multicast datagram
  985.         sent from a member of the destination group is now made at the
  986.         time the datagram is sent, rather than at the time the group
  987.         is joined.  This gives the sender another degree of scope
  988.         control, beyond the IP time-to-live.
  989.  
  990.       - The handling of IP time-to-live, and of multiple network
  991.         interfaces, has been more precisely specified.
  992.  
  993.       - Hosts are no longer allowed to place an IP host group address
  994.         in a source routing option.
  995.  
  996.       - The AcceptAddress and RejectAddress operations at the local
  997.         network service interface have been renamed JoinLocalGroup and
  998.         LeaveLocalGroup to emphasize their semantic similarity to the
  999.         JoinHostGroup and LeaveHostGroup operations at the IP service
  1000.         interface.
  1001.  
  1002.  
  1003.  
  1004. Deering                                                        [Page 18]
  1005.  
  1006. RFC 1054          Host Extensions for IP Multicasting           May 1988
  1007.  
  1008.  
  1009.       - A new mapping algorithm for Ethernet multicast addresses has
  1010.         been specified.
  1011.  
  1012.       - The organization of the memo has been changed somewhat, and a
  1013.         state transition diagram has been added to the IGMP
  1014.         specification.
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.  
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060. Deering                                                        [Page 19]
  1061.  
  1062.